I need some help with getting Agent-Canvas to work. I installed it in a Docker container running on Unraid, and I made a connection with the backend. However, i can't make a connection with the Ollama container running also on Unraid, where my models are stored. I do a test i get an error like this: litellm.APIConnectionError: OllamaException - Cannot connect to host host. docker.internal:11434 ssl:<ssl.SSLContext object at 0x14b6591dd130> [Connect call failed ('192.168.X.X', 11434)] I don't understand this cause i don't know why it looking for an SSL connection while I just want it to connect internally to my Ollama container. I also don't know why I failed to connect to a different IP address, which I did not configure. The IP address it is mentioned as failed is the IP address of my reverse proxy. I don't know why it connects to that ip address with the port number of the Ollama container.

Thanks @modern-garden-55994, interesting setup! Could you share the exact docker commands you ran for both openhands and ollama?

You mean the Docker Compose file of Ollama? and that of openhand Agent-Canvas?

Yes, I’d like to know the two command that you ran so I can try to reproduce the error.

Let me see if i can post the docker compose here of both the containers

OK, thanks. Did you run any command line commands? Could you share those?

No, I did not run any command-line command. i prefer to do everything through Docker Compose

OK, got it. This might be easier for us to reproduce if we can get step-by-step instructions for how to run the program the same way you did.

the two Docker compose file are the only two things needed. You can run Ollama also in Portainer. You don't need Unraid. Most of the settings are environment variables

I’m sorry, your explanation so far hasn’t been clear enough for us to reproduce the problem. We’d need step-by-step directions

But you haven't told me what you need exactly. You just ignored me till i asked you. You could have responded and asked me for additional information. I have sent you all the information you asked me for so far. If you want more, you can just ask

I said:

OK, got it. This might be easier for us to reproduce if we can get step-by-step instructions for how to run the program the same way you did.

But you did not give me step-by-step instructions. They need to be more concrete than a couple screenshots. If you’re not sure what I’m talking about, take a look at the instructions we have in the openhands docs. You’ll see how they say things like “first, do this, then do this” etc.

I will provide you a Docker Compose file without the use of Unraid. You need to have a Docker environment to run it as a container. Are you familiar with the docker-compose up command to start a container? If you prefer to run is without Docker Compose, I can convert it for you

Yep, if I have a full docker compose file, and then instructions about how you clicked through the interface after ollama and the agent canvas came up then I can probably use that to reproduce.

i told you that at the beginning of the conversation. I just ran the Docker Compose file of agent-canvast, and then I connected to the web UI, which in my case is the IP of my Unraid / 8042. I could not use 8000 because it is already used by Portainer. In the webui i configure the backend, and i said it is running; that was it.

OK, if you can share the docker compose file we could probably try it

services:

ollama:

container_name: ollama

networks:

- ai-net # change it to match your environment

restart: always

image: "ollama/ollama"

ports:

- "11434:11434"

volumes:

- /volume1/docker/ollama:/root/.ollama # change it to match your environment

environment:

- OLLAMA_HOST=0.0.0.0:11434

- OLLAMA_ORIGINS=*

- OLLAMA_KEEP_ALIVE=-1

- OLLAMA_MODELS=/root/.ollama/models

networks:

ai-net:

external: true

And the one for agent canvas?

# ignored : docker/podman mkdir -p ~/projects ~/.openhands

name: <openhands_agent-canvas>

services:

agent-canvas:

stdin_open: true

tty: true

container_name: agent-canvas

networks:

- ai-net # change it to match your environment

ports:

- 8082:8000 # port 8000 was already taken

volumes:

- /mnt/user/appdata/openhands:/home/openhands/.openhands:rw # change it to match your environment

- /mnt/user/appdata/projects:/projects:rw  # change it to match your environment

image: <http://ghcr.io/openhands/agent-canvas:latest|ghcr.io/openhands/agent-canvas:latest>

restart: unless-stopped

networks:

ai-net:

external: true

Thanks for sharing the Compose files. I believe the issue is the Ollama URL configured in Agent Canvas. Since both containers are attached to the external Docker network

ai-net

, Agent Canvas should reach Ollama using the container name—not

host.docker.internal

or the reverse-proxy address. In the Agent Canvas LLM settings, please use: - Provider: Ollama - Ollama Base URL:

<http://ollama:11434>

- Model: the exact model name installed in Ollama, such as

llama3.2

- API key: leave empty unless the UI requires one Please make sure the shared network exists and both containers are connected to it:

bash
docker network create ai-net
docker network inspect ai-net

The

docker network inspect

output should list both

ollama

and

agent-canvas

. You can also test connectivity directly from the Agent Canvas container:

bash
docker exec -it agent-canvas sh
curl <http://ollama:11434/api/tags>

That should return Ollama’s model list. If it does not, the two containers are not actually sharing the same Docker network. The

ssl:<ssl.SSLContext ...>

text in the error does not necessarily mean HTTPS was configured. The main problem is that

host.docker.internal

resolves to the Docker host/reverse proxy rather than the Ollama container. Use

<http://ollama:11434>

for direct container-to-container communication. This response was prepared by an AI agent (OpenHands) on behalf of the user.

I did the docker exec command and it showed me all the models that are currtely installed on Ollama

That’s useful—if

docker exec ... curl <http://ollama:11434/api/tags>

showed your models, then the Docker networking is working. The remaining problem is the Agent Canvas LLM configuration, not connectivity. You do not need to select

Ollama

in the Provider field if that field is unavailable. In the Advanced or All settings view, try configuring: - Model:

ollama/<exact-model-name>

(replace this with the name shown by `/api/tags`; for example,

ollama/llama3.2

) - Ollama Base URL:

<http://ollama:11434>

- Base URL, if that is the only URL field available:

<http://ollama:11434>

- API key: leave empty, or use a placeholder only if the form requires a value The important part is that the model name uses the Ollama provider prefix and the URL is the internal Docker hostname. Do not enter

host.docker.internal

, your reverse-proxy hostname, or

https://

. After saving the settings, start a new conversation so it uses the updated LLM configuration. If the settings page does not expose either

Ollama Base URL

or

Base URL

, please share a screenshot of the All settings fields (with any credentials/API keys hidden), along with the exact Agent Canvas image tag/version. Then we can identify which field maps to LiteLLM’s

api_base

for that version. This follow-up was prepared by an AI agent (OpenHands) on behalf of the user.

It seems that it finally works. if i use llama3.2 it give me an error that the model is not suitable for thinking. Then i change it and choose qwen3-v1:8b. the model asked me what i want to build and i answer with a prompt " a webiste". The model then throw an error like this: Your last response did not include a function call or a message. Please use a tool to proceed with the task.

Good progress: the Docker connection is working. The remaining issue is likely the Ollama model configuration. First, list the exact installed model names from inside the Agent Canvas container:

bash
curl -s <http://ollama:11434/api/tags>

Use the exact

name

returned there.

curl <http://ollama>

is not the model-list endpoint. Your Ollama Compose file also needs a larger context window. OpenHands’ current local-LLM documentation says the Ollama default of 4096 tokens is too small; use at least 22000, or 32768 if your hardware allows it:

yaml
environment:
  - OLLAMA_HOST=0.0.0.0:11434
  - OLLAMA_CONTEXT_LENGTH=22000
  - OLLAMA_KEEP_ALIVE=-1
  - OLLAMA_ORIGINS=*

After changing this, recreate/restart the Ollama container; changing the Compose file alone does not update an existing container. For Agent Canvas, use:

text
Model: ollama/<exact-name-from-api-tags>
Base URL: <http://ollama:11434>
API key: local-llm

Replace the model placeholder with the exact installed model name. Do not use

host.docker.internal

, the reverse-proxy hostname, or

https://

. The

qwen3-v1:8b

error—“Your last response did not include a function call or a message”—means the model connected but did not produce a valid OpenHands tool call or assistant message. Small/general models can work for chat but fail at agent tool calling. Try a coding-oriented instruct model instead. The current OpenHands docs recommend `Qwen3.6-35B-A3B`;

qwen2.5-coder-14b-instruct

is another community-reported option. Use the exact Ollama tag available in your

/api/tags

output. The

llama3.2

“not suitable for thinking” error is also a model-capability mismatch, not a Docker-network problem. After updating the context length and selecting a suitable coding model, save the settings and start a new conversation. Current documentation: https://docs.openhands.dev/openhands/usage/llms/local-llms This response was prepared by an AI agent (OpenHands) on behalf of the user.

I used the exact name that you advised

curl -s <http://ollama:11434/api/tags>    but it only listed Qwen model and not the other models.

Thanks for the screenshot—that clarifies that the Ollama environment variables are already configured. Since

curl <http://ollama:11434/api/tags>

returns only Qwen, Agent Canvas is reaching an Ollama instance whose current model store contains only Qwen. This is not an SSL or LiteLLM routing problem. Please verify the following in Portainer: 1. Open the Ollama container console and run:

bash
   ollama list

2. In the Agent Canvas container console, run:

bash
   getent hosts ollama
   curl -s <http://ollama:11434/api/tags>

3. Compare the two outputs. They should show the same model list. 4. In Ollama’s container settings, check the volume mounted at

/root/.ollama

. Make sure it is the directory where

deepseek-r1:14b-qwen-distill-q4_K_M

and the other models were actually downloaded. If the models were downloaded in a different Ollama container or volume, the current container will not see them. 5. Check that there is only one container named/aliased

ollama

on the shared

ai-net

network. A stale second Ollama container can make the hostname resolve to the wrong instance. If

ollama list

itself shows only Qwen, pull the missing model into this exact container, for example:

bash
ollama pull deepseek-r1:14b-qwen-distill-q4_K_M

Then repeat

curl -s <http://ollama:11434/api/tags>

. For Agent Canvas, keep the model field as

ollama/<exact name returned by /api/tags>

and the base URL as

<http://ollama:11434>

. Do not add

https://

or use the reverse-proxy address. The Qwen error (“last response did not include a function call or a message”) is a separate model-compatibility issue: the model connected, but it did not emit a valid OpenHands tool call. Once the model list is corrected, test with an instruct/coding model that supports tool use and start a new conversation. The context-length setting can affect long tasks, but it would not explain why

/api/tags

lists only Qwen. This response was prepared by an AI agent (OpenHands) on behalf of the user.

(other smaller versions of qwen-3.6 should also be good)

image.png

What’s shown in the “thinking”?

image.png

Ok, I'm done for the day but can take another look later

no problem. Goodnight. We talk tomorrow